1. Field of Invention
The present invention relates to interactive voice response (“IVR”) systems, and more particularly to maintaining the IVR system specification, which includes both the data for the various state definitions as well as documentation for the IVR system.
2. Description of Related Art
Interactive Voice Response (“IVR”) systems allow a consumer to use a telephone keypad or voice commands to receive self service with a company's contact center without assistance from a contact center agent. For example, a customer of a credit card company may call its toll-free number, type or say her account number and a PIN, and hear information about her current balance, available credit, and next payment due date. By enabling customers to help themselves, IVR systems enable a contact center to handle more customers at one time than the available contact center agents could handle directly.
While IVR systems provide useful contact center functionality, they are not simple for a company to design, build, and maintain. IVR systems often have complicated, web-like, structures of content and numerous user touch-points. There are often different owners (including business and IT personnel) within a company for the various types of content needed to operate an IVR system. These business owners use differing techniques for documenting and maintaining their piece of the system. For example, the system test team may keep the scripts necessary for system and regression testing in one or more spreadsheets. The marketing team may use Visio or another graphical application to visually show the design flow for the customer experience when using the IVR system. A business analyst may maintain a word processing document to capture the details for each step or menu concerning payments. Other groups, with overlapping responsibilities, may use other forms of documentation.
The complicated interconnections within the IVR system, the supporting specifications for the system and the fact that the system is owned by a wide-spread group of business owners makes changing the system difficult. Even a small change to the IVR system requires multiple contacts to the business owners, who then are entrusted to each update their own documents to reflect the change. When changes are made to the system, its complicated nature makes it difficult to closely track the changes over time. The IVR administrator may try to manually compile a document of changes made to the IVR system between two versions. However, this manual process is inconvenient, time consuming, and ripe for mistakes.
FIG. 1 illustrates the prior art's approach to maintaining the design of an IVR system. In such systems, a single change that is to introduced to the IVR requires manual changes 105 to one or more of the following types of IVR system documentation: the design flow document 110, the test scripts document 120, the change history document 125, the recording prompt list document 130, the state definition details document 135, and/or the sample dialogues document 140. Some of these (110 for example) may be VISIO, POWERPOINT or other graphical files. Some (120 for example) may be EXCEL or other spreadsheets. Some of these documents (125, 130, 135, 140 for example) may be WORD or other word processing documents. Of course, this list of documentation is merely representative of documents that may be maintained. It is to be understood that different companies may maintain information about their IVR systems using different types of documents than the representative ones shown in FIG. 1. Regardless, if any of these manual changes 105 are missed, the reference data is no longer accurate. Since the various documents are owned by different groups, it is not difficult for this to happen.
What is needed is a system for centralizing the IVR system specification for an IVR system that is usually stored in several different applications, such as word processor, a spreadsheet application and a graphical application. What is a needed is a system that enables a change in the IVR system (whether it be a change to some state definition data or a change to IVR system documentation) to be entered once and yet reflected throughout the data and documentation for the system. Finally, what is needed is a system for tracking changes that can easily and accurately report modifications made to the IVR system specification for a specific time period or between two specified versions.